home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1994 August: Tool Chest / Dev.CD Aug 94.toast / Tool Chest / Development Platforms / Macintosh Common Lisp Related / Lisp FAQ 21Sept93 / 2.General Questions < prev    next >
Encoding:
Internet Message Format  |  1993-09-21  |  32.8 KB  |  [TEXT/ttxt]

  1. Subject: FAQ: Lisp Frequently Asked Questions 2/7 [Monthly posting]
  2. Newsgroups: comp.lang.lisp,news.answers,comp.answers
  3. Summary: Frequently asked questions about Lisp -- General Questions
  4. Distribution: world
  5. Followup-To: poster
  6. Reply-To: lisp-faq@think.com
  7. Approved: news-answers-request@MIT.Edu
  8.  
  9. Archive-name: lisp-faq/part2
  10. Last-Modified: Mon Sep 13 20:13:07 1993 by Mark Kantrowitz
  11. Version: 1.38
  12.  
  13. ;;; ****************************************************************
  14. ;;; Answers to Frequently Asked Questions about Lisp ***************
  15. ;;; ****************************************************************
  16. ;;; Written by Mark Kantrowitz and Barry Margolin
  17. ;;; lisp-faq-2.text -- 33558 bytes
  18.  
  19. This post contains Part 2 of the Lisp FAQ.
  20.  
  21. If you think of questions that are appropriate for this FAQ, or would
  22. like to improve an answer, please send email to us at lisp-faq@think.com.
  23.  
  24. Topics Covered (Part 2):
  25.  
  26.   [2-1]   Is there a GNU-Emacs interface to Lisp?
  27.   [2-2]   When should I use a hash table instead of an association list?
  28.   [2-3]   What is the equivalent of EXPLODE and IMPLODE in Common Lisp?
  29.   [2-4]   Is Lisp inherently slower than more conventional languages such as C?
  30.   [2-5]   Why does Common Lisp have "#'"?
  31.   [2-6]   How do I call non-Lisp functions from Lisp?
  32.   [2-7]   Can I call Lisp functions from other languages?
  33.   [2-8]   I want to call a function in a package that might not exist at
  34.           compile time. How do I do this?  
  35.   [2-9]   What is CDR-coding?
  36.   [2-10]  What is garbage collection?
  37.   [2-11]  How do I save an executable image of my loaded Lisp system?
  38.           How do I run a Unix command in my Lisp?
  39.           How do I get the current directory name from within a Lisp program?
  40.   [2-12]  I'm porting some code from a Symbolics Lisp machine to some
  41.           other platform, and there are strange characters in the code.
  42.           What do they mean?  
  43.   [2-13]  History: Where did Lisp come from?
  44.   [2-14]  How do I find the argument list of a function?
  45.           How do I get the function name from a function object?
  46.   [2-15]  How can I have two Lisp processes communicate via unix sockets?
  47.   [2-16]  How can I create a stream that acts like UNIX's /dev/null
  48.           (i.e., gobbles any output and immediately signals EOF on
  49.           input operations)?
  50.    
  51.  
  52. Search for \[#\] to get to question number # quickly.
  53.  
  54. ----------------------------------------------------------------
  55. Subject: [2-1] Is there a GNU-Emacs interface to Lisp?
  56.  
  57. ILISP is a powerful GNU-Emacs interface to many dialects of Lisp,
  58. including Lucid, Allegro, {A}KCL, IBCL, and CMU. Written by Chris
  59. McConnell <ccm+@cs.cmu.edu> and now maintained by Ivan Vazquez
  60. <ivan@haldane.bu.edu>. It is available by anonymous ftp from
  61. haldane.bu.edu [128.197.54.25] in the directory pub/ilisp as the file
  62. ilisp.tar.Z. If you want to be on the ilisp mailing list, to hear about
  63. new releases and patches, send mail to ilisp-request@darwin.bu.edu
  64. Please send any comments or code to ilisp@darwin.bu.edu. Bugs should
  65. be sent to ilisp-bug@darwin.bu.edu (or ilisp-bugs@darwin.bu.edu).
  66.  
  67. Franz Inc.'s GNU-Emacs/Lisp interface includes an online Common
  68. Lisp manual. It is available by license from Franz Inc. Contact
  69. info@franz.com for more information. The Emacs-Lisp interface (without
  70. the online Common Lisp reference manual and some Allegro-specific code)
  71. is available free from
  72.    ftp.uu.net:/vendor/franz/emacs/emacs-lisp-2.0.4.tar.Z
  73. There is also a mailing list, lisp-emacs-forum-request@ucbarpa.berkeley.edu.
  74. (See also [1-2] for a hardcopy version of the Common Lisp reference manual.)
  75.  
  76. The cl-shell package provides a major mode (cl-shell-mode) for running
  77. Common Lisp (CL) as an Emacs subprocess.  It provides a general
  78. mechanism for communication between CL and Emacs which does not rely
  79. on extra processes, and should therefore be easily portable to any
  80. version of CL.  Features include direct (i.e., not through a temp file)
  81. evaluation and in-package compilation of forms from lisp-mode buffers,
  82. type-ahead and a history mechanism for the cl-shell buffer, and pop-up
  83. help facilities for the CL functions documentation, macroexpand and
  84. describe.  Extensions for Lucid Common Lisp provide pop-up arglists
  85. and source file editing.  Other extensions are provided to allow
  86. editing source files of CLOS or Flavors methods.  Cl-shell is
  87. available on the Lucid tape (in the goodies directory) or via
  88. anonymous ftp from whitechapel.media.mit.edu (18.85.0.125).
  89.  
  90. Lucid includes some other Emacs-Lisp interfaces in its goodies directory.
  91.  
  92. Harlequin's LispWorks includes an Emacs-Lisp interface.
  93.  
  94. Venue's Medley has an optional EMACS Interface.
  95.  
  96. GNU-Emacs itself is available by anonymous ftp from prep.ai.mit.edu.
  97.  
  98. ----------------------------------------------------------------
  99. Subject: [2-2] When should I use a hash table instead of an association list?
  100.  
  101. Both association lists (alists) and hash tables may be used to represent
  102. tabular data. Hash tables have an O(1) running time and alists an O(n)
  103. running time, so hash tables are ultimately more efficient than
  104. alists. However, if the alists are small, they can be more efficient
  105. than hash tables, which have a large initial overhead.
  106.  
  107. In Allegro CL 4.1 [SPARC; R1], the rule of thumb is that for less than
  108. 24 elements, linear search using alists beats hashing.  In Lucid CL
  109. 4.0.1 HP 9000/700, the break-even point is at 10 elements. The
  110. break-even points vary in other lisps from as low as 4 elements to as
  111. high as 100 elements. So if you're using alists in your code, using 
  112. hash tables instead may speed up your program. 
  113.  
  114. ----------------------------------------------------------------
  115. Subject: [2-3] What is the equivalent of EXPLODE and IMPLODE in Common Lisp?
  116.  
  117. Hopefully, the only reason you need to do this is as part of trying to port
  118. some old MacLisp code to Common Lisp.  These functions predated the
  119. inclusion of strings as a first-class data type in Lisp; symbols were used
  120. as strings, and they ere EXPLODEd to allow the individual characters to be
  121. manipulated in a list.
  122.  
  123. Probably the best approximations of these are:
  124.  
  125.    (defun explode (object)
  126.      (loop for char across (prin1-to-string object)
  127.            collect (intern (string char))))
  128.  
  129.    (defun implode (list)
  130.      (read-from-string (coerce (mapcar #'character list) 'string)))
  131.  
  132. An alternate definition of EXPLODE which uses MAP instead of LOOP is:
  133.  
  134.    (defun explode (object)
  135.      (map 'list #'(lambda (char) 
  136.                     (intern (string char)))
  137.           (prin1-to-string object)))
  138.  
  139. The creation of N conses of garbage to process a string of N
  140. characters is a hideously inefficient way of doing the job.  Rewrite
  141. EXPLODE code with PRIN1-TO-STRING, or better STRING if the arguments
  142. are symbols without funny characters.  For IMPLODE, try to make its
  143. caller use strings and try to make the result usable as a string to
  144. avoid having to call INTERN or READ-FROM-STRING.
  145.  
  146. ----------------------------------------------------------------
  147. Subject: [2-4] Is Lisp inherently slower than more conventional languages
  148.                such as C?
  149.  
  150. This is a tough question to answer, as you probably expected.  In many
  151. cases, it appears to be.  Lisp does not require the programmer to specify
  152. the data type of variables, so generic arithmetic operators may have to
  153. perform type checking at runtime in order to determine how to proceed.
  154. However, Lisp code can also be denser (i.e.  there is more expressed in a
  155. single line) than many other languages: the Lisp expression (+ A B) is more
  156. powerful than the C expression A+B (the Lisp version supports bignums,
  157. rationals, and complex numbers, while the C version only supports
  158. limited-size integers and floating point); therefore, one may claim that it
  159. is reasonable that the Lisp version take longer than the C version (but
  160. don't expect everyone to accept this rationalization).  Solutions to this
  161. include hardware support (e.g. processors that support type tags in data,
  162. such as SPARC and Symbolics Lisp Machines), declarations, and specialized
  163. variants of functions (e.g. in MacLisp, + accepts and returns only fixnums,
  164. +$ accepts and returns only flonums, and PLUS is generic).
  165.  
  166. At one time, the MIT PDP-10 MacLisp compiler was compared to DEC's
  167. PDP-10 Fortran compiler.  When appropriate declarations were supplied
  168. in the Lisp code, the performance of compiled Lisp arithmetic rivaled
  169. that of the Fortran code.  It would hardly be fair to compare Lisp
  170. without declarations to Fortran, since the Fortran compiler would have
  171. more information upon which it could base its optimizations. A more
  172. recent test found that numeric code compiled with optimizations using
  173. CMU CL is within the same ballpark as highly optimized Fortran code.
  174. For unoptimized Fortran code, CMU CL was about 4 times faster.
  175. Even the speed of numeric code generated by other Lisp compilers
  176. (AKCL, Allegro, Lucid) was well within an order of magnitude of good
  177. Fortran and C compilers (although slower than CMU CL).  Inspection of
  178. the emitted C code from AKCL doesn't reveal many obvious sources of
  179. inefficiency. (Since AKCL compiles Lisp into C, there are many cases
  180. where KCL code is as fast as hand-written C code.)
  181.  
  182. See the paper peoplesparc.berkeley.edu:~ftp/pub/papers/fastlisp.ps.Z
  183. for a discussion of the speed of Lisp vis a vis Fortran or C.
  184.  
  185. Since Lisp is a good language for rapid prototyping, it is easy for a
  186. mediocre programmer (or even a good programmer, who isn't being careful) to
  187. generate a large amount of inefficient Lisp code. A good example is the use
  188. of APPEND to link successive lists together, instead of keeping a pointer
  189. to the tail of the list. Often a programmer can obtain significant
  190. speed increases by using a time/space profiler to identify the
  191. functions which waste time (often small functions which are called
  192. frequently) and rewriting those functions.
  193.      
  194. ----------------------------------------------------------------
  195. Subject: [2-5] Why does Common Lisp have "#'"?
  196.  
  197. #' is a macro-character which expands #'FOO to (FUNCTION FOO).  Symbols in
  198. Lisp have two bindings, one for values and one for functions, allowing them
  199. to represent both variables and functions, depending on context. #'FOO
  200. accesses FOO's lexical function binding in a context where the value
  201. interpretation would normally occur.  #' is also used to create lexical
  202. closures for lambda expressions. A lexical closure is a function which when
  203. invoked executes the body of the lambda-expression in the lexical
  204. environment within which the closure was created.  See pp. 115-117 of CLtL2
  205. for more details.
  206.  
  207. ----------------------------------------------------------------
  208. Subject: [2-6] How do I call non-Lisp functions from Lisp?
  209.  
  210. Most Lisp implementations for systems where Lisp is not the most common
  211. language provide a "foreign function" interface.  As of now there has been
  212. no significant standardization effort in this area.  They tend to be
  213. similar, but there are enough differences that it would be inappropriate to
  214. try to describe them all here.  In general, one uses an
  215. implementation-dependent macro that defines a Lisp function, but instead of
  216. supplying a body for the function, one supplies the name of a function written
  217. in another language; the argument list portion of the definition is
  218. generally augmented with the data types the foreign function expects and
  219. the data type of the foreign function's return value, and the Lisp
  220. interface function arranges to do any necessary conversions.  There is also
  221. generally a function to "load" an object file or library compiled in a
  222. foreign language, which dynamically links the functions in the file being
  223. loaded into the address space of the Lisp process, and connects the
  224. interface functions to the corresponding foreign functions.
  225.  
  226. If you need to do this, see the manual for your language implementation for
  227. full details.  In particular, be on the lookout for restrictions on the
  228. data types that may be passed.  You may also need to know details about the
  229. linkage conventions that are used on your system; for instance, many C
  230. implementations prepend an underscore onto the names of C functions when
  231. generating the assembler output (this allows them to use names without
  232. initial underscores internally as labels without worrying about conflicts),
  233. and the foreign function interface may require you to specify this form
  234. explicitly.
  235.  
  236. Franz Allegro Common Lisp's "Foreign Function Call Facility" is
  237. described in chapter 10 of the documentation. Calling Lisp Functions
  238. from C is treated in section 10.8.2. The foreign function interface in
  239. Macintosh Common Lisp is similar. The foreign function interface for
  240. KCL is described in chapter 10 of the KCL Report. The foreign function
  241. interfaces for Lucid on the Vax and Lucid on the Sun4 are
  242. incompatible. Lucid's interface is described in chapter 5 of the
  243. Advanced User's Guide.
  244.  
  245. ----------------------------------------------------------------
  246. Subject: [2-7] Can I call Lisp functions from other languages?
  247.  
  248. In implementations that provide a foreign function interface as described
  249. above, there is also usually a "callback" mechanism.  The programmer may
  250. associate a foreign language function name with a Lisp function.  When a
  251. foreign object file or library is loaded into the Lisp address space, it is
  252. linked with these callback functions.  As with foreign functions, the
  253. programmer must supply the argument and result data types so that Lisp may
  254. perform conversions at the interface. Note that in such foreign function
  255. interfaces Lisp is often left "in control" of things like memory
  256. allocation, I/O channels, and startup code (this is a major nuisance
  257. for lots of people).
  258.      
  259. ----------------------------------------------------------------
  260.  
  261. Subject: [2-8]  I want to call a function in a package that might not exist at
  262.                 compile time. How do I do this?
  263.  
  264. Use (funcall (find-symbol "SYMBOL-NAME" :pkg-name) ...).
  265.  
  266. ----------------------------------------------------------------
  267. Subject: [2-9]  What is CDR-coding?
  268.  
  269. CDR-coding is a space-saving way to store lists in memory.  It is normally
  270. only used in Lisp implementations that run on processors that are
  271. specialized for Lisp, as it is difficult to implement efficiently
  272. in software.  In normal list structure, each element of the
  273. list is represented as a CONS cell, which is basically two pointers (the
  274. CAR and CDR); the CAR points to the element of the list, while the CDR
  275. points to the next CONS cell in the list or NIL.  CDR-coding takes
  276. advantage of the fact that most CDR cells point to another CONS, and
  277. further that the entire list is often allocated at once (e.g. by a call to
  278. LIST).  Instead of using two pointers to implement each CONS cell, the CAR
  279. cell contains a pointer and a two-bit "CDR code".  The CDR code may contain
  280. one of three values: CDR-NORMAL, CDR-NEXT, and CDR-NIL.  If the code is
  281. CDR-NORMAL, this cell is the first half of an ordinary CONS cell pair, and
  282. the next cell in memory contains the CDR pointer as described above.  If
  283. the CDR code is CDR-NEXT, the next cell in memory contains the next CAR
  284. cell; in other words, the CDR pointer is implicitly thisaddress+1, where
  285. thisaddress is the memory address of the CAR cell.  If the CDR code is
  286. CDR-NIL, then this cell is the last element of the list; the CDR pointer is
  287. implicitly a reference to the object NIL.  When a list is constructed
  288. incrementally using CONS, a chain of ordinary pairs is created; however,
  289. when a list is constructed in one step using LIST or MAKE-LIST, a block of
  290. memory can be allocated for all the CAR cells, and their CDR codes all set
  291. to CDR-NEXT (except the last, which is CDR-NIL), and the list will only
  292. take half as much storage (because all the CDR pointers are implicit).
  293.  
  294. If this were all there were to it, it would not be difficult to implement
  295. in software on ordinary processors; it would add a small amount of overhead
  296. to the CDR function, but the reduction in paging might make up for it.  The
  297. problem arises when a program uses RPLACD on a CONS cell that has a CDR
  298. code of CDR-NEXT or CDR-NIL.  Normally RPLACD simply stores into the CDR
  299. cell of a CONS, but in this case there is no CDR cell -- its contents are
  300. implicitly specified by the CDR code, and the word that would normally
  301. contain the CDR pointer contains the next CONS cell (in the CDR-NEXT case)
  302. to which other data structures may have pointers, or the first word of some
  303. other object (in the CDR-NIL case).  When CDR-coding is used, the
  304. implementation must also provide automatic "forwarding pointers"; an
  305. ordinary CONS cell is allocated, the CAR of the original cell is copied
  306. into its CAR, the value being RPLACD'ed is stored into its CDR, and the old
  307. CAR cell is replaced with a forwarding pointer to the new CONS cell.
  308. Whenever CAR or CDR is performed on a CONS, it must check whether the
  309. location contains a forwarding pointer.  This overhead on both CAR and CDR,
  310. coupled with the overhead on CDR to check for CDR codes, is generally
  311. enough that using CDR codes on conventional hardware is infeasible.
  312.  
  313. There is some evidence that CDR-coding doesn't really save very much
  314. memory, because most lists aren't constructed at once, or RPLACD is done on
  315. them enough that they don't stay contiguous.  At best this technique can
  316. save 50% of the space occupied by CONS cells. However, the savings probably
  317. depends to some extent upon the amount of support the implementation
  318. provides for creating CDR-coded lists.  For instance, many system functions
  319. on Symbolics Lisp Machines that operate on lists have a :LOCALIZE option;
  320. when :LOCALIZE T is specified, the list is first modified and then copied
  321. to a new, CDR-coded block, with all the old cells replaced with forwarding
  322. pointers.  The next time the garbage collector runs, all the forwarding
  323. pointers will be spliced out.  Thus, at a cost of a temporary increase in
  324. memory usage, overall memory usage is generally reduced because more lists
  325. may be CDR-coded. There may also be some benefit in improved paging
  326. performance due to increased locality as well (putting a list into
  327. CDR-coded form makes all the "cells" contiguous). Nevertheless, modern
  328. Lisps tend to use lists much less frequently, with a much heavier
  329. reliance upon code, strings, and vectors (structures).
  330.  
  331. ----------------------------------------------------------------
  332. Subject: [2-10] What is garbage collection?
  333.  
  334. Garbage Collection (GC) refers to the automatic storage allocation
  335. mechanisms present in many Lisps. There are several kinds of storage
  336. allocation algorithms, but most fall within two main classes:
  337.  
  338.    1. Stop and Copy. Systems which copy active objects from "old"
  339.       storage to "new" storage and then recycle the old storage.
  340.  
  341.    2. Mark and Sweep. Systems which link together storage
  342.       used by discarded objects. 
  343.  
  344. Generational scavenging garbage collection (aka emphemeral GC) is a
  345. variation in which memory is allocated in layers, with tenured
  346. (long-lived) objects in the older layers. Rather than doing a full GC
  347. of all of memory every time more room is needed, only the last few
  348. layers are GCed during an ephemeral GC, taking much less time.
  349. Short-lived objects are quickly recycled, and full GCs are then much
  350. less frequent. It is most often used to improve the performance of
  351. stop and copy garbage collectors.  It is possible to implement
  352. ephemeral GC in mark and sweep systems, just much more difficult.
  353.  
  354. Stop and copy garbage collection provides simpler storage allocation,
  355. avoids fragmentation of memory (intermixing of free storage with used
  356. storage). Copying, however, consumes more of the address space, since up to
  357. half the space must be kept available for copying all the active objects.
  358. This makes stop and copy GC impractical for systems with a small address
  359. space or without virtual memory.  Also, copying an object requires that you
  360. track down all the pointers to an object and update them to reflect the new
  361. address, while in a non-copying system you need only keep one pointer to an
  362. object, since its location will not change. It is also more difficult to
  363. explicitly return storage to free space in a copying system.
  364.  
  365. Garbage collection is not part of the Common Lisp standard. Most Lisps
  366. provide a function ROOM which provides human-readable information about the
  367. state of storage usage. In many Lisps, (gc) invokes an ephemeral garbage
  368. collection, and (gc t) a full garbage collection.
  369.  
  370. ----------------------------------------------------------------
  371. Subject: [2-11] How do I save an executable image of my loaded Lisp system?
  372.                 How do I run a Unix command in my Lisp?
  373.                 How do I get the current directory name from within a Lisp 
  374.                 program?
  375.  
  376. There is no standard for dumping a Lisp image. Here are the
  377. commands from some lisp implementations:
  378.    Lucid:               DISKSAVE
  379.    Symbolics:           Save World  [CP command]
  380.    CMU CL:              SAVE-LISP
  381.    Franz Allegro:       EXCL:DUMPLISP (documented) 
  382.                         SAVE-IMAGE (undocumented)
  383.    Medley:              IL:SYSOUT or IL:MAKESYS
  384.    MCL:                 SAVE-APPLICATION <pathname>
  385.                           &key :toplevel-function  :creator :excise-compiler
  386.                           :size :resources :init-file :clear-clos-caches
  387.    KCL:                 (si:save-system "saved_kcl")
  388.    LispWorks:        LW:SAVE-IMAGE
  389.  
  390. There is no standard for running a Unix shell command from Lisp,
  391. especially since not all Lisps run on top of Unix. Here are the
  392. commands from some Lisp implementations:
  393.    Allegro:             EXCL:RUN-SHELL-COMMAND
  394.    Lucid:               RUN-PROGRAM (name 
  395.                                      &key input output
  396.                                           error-output (wait t) arguments
  397.                                           (if-input-does-not-exist :error)
  398.                                           (if-output-exists :error)
  399.                                           (if-error-output-exists :error))
  400.    KCL:                 SYSTEM 
  401.                         For example, (system "ls -l").
  402.                         You can also try RUN-PROCESS and EXCLP, but they
  403.                         don't work with all versions of KCL.
  404.    CMU CL:              RUN-PROGRAM (program args
  405.                &key (env *environment-list*) (wait t) pty input
  406.                if-input-does-not-exist output
  407.                (if-output-exists :error) (error :output) 
  408.                (if-error-exists :error) status-hook before-execve)
  409.    LispWorks:           FOREIGN:CALL-SYSTEM-SHOWING-OUTPUT
  410.  
  411. There's no standard function for finding the current directory from
  412. within a Lisp program, since not all Lisp environments have the
  413. concept of a current directory. Here are the commands from some Lisp
  414. implementations:
  415.    Lucid:               WORKING-DIRECTORY (which is also SETFable)
  416.                         PWD and CD also work
  417.    Allegro:             CURRENT-DIRECTORY (use excl:chdir to change it)
  418.    CMU CL:              DEFAULT-DIRECTORY
  419.    LispWorks:           LW:*CURRENT-WORKING-DIRECTORY* 
  420.                         (use LW:CHANGE-DIRECTORY to change it)
  421.  
  422. Allegro also uses the variable *default-pathname-defaults* to resolve
  423. relative pathnames, maintaining it as the current working directory.
  424. So evaluating (truename "./") in Allegro (and on certain other
  425. systems) will return a pathname for the current directory. Likewise,
  426. in some VMS systems evaluating (truename "[]") will return a pathname
  427. for the current directory.
  428.  
  429. To toggle source file recording and cross-reference annotations, use
  430.    Allegro:             excl:*record-source-file-info*
  431.             excl:*load-source-file-info* 
  432.             excl:*record-xref-info*
  433.             excl:*load-xref-info*
  434.    LispWorks:           (toggle-source-debugging nil)
  435.  
  436. Memory management:
  437.    CMU CL:              (bytes-consed-between-gcs)  [this is setfable]
  438.    Lucid:        (change-memory-management 
  439.                      &key growth-limit expand expand-reserved)
  440.    Allegro:        *tenured-bytes-limit*
  441.    LispWorks:           LW:GET-GC-PARAMETERS
  442.                         (use LW:SET-GC-PARAMETERS to change them)
  443.  
  444. ----------------------------------------------------------------
  445. Subject: [2-12] I'm porting some code from a Symbolics Lisp machine to some
  446.                 other platform, and there are strange characters in the code.
  447.                 What do they mean?
  448.  
  449. The Symbolics Zetalisp character set includes the following
  450. characters not present in other Lisps (^ means control):
  451.    ^]      >=      greater than or equal to
  452.    ^\      <=      less than or equal to
  453.    ^Z      !=      not equal to
  454.    ^^      ==      equivalent to 
  455.    ^E      not
  456.    ^G      pi
  457.    ^L      +/-     plus/minus
  458.    ^H      lambda
  459.    ^F      epsilon
  460.    ^W      <-->    left/right arrow
  461.    ^X      <--     left arrow
  462.    ^Y      -->     right arrow
  463.    ^A              down arrow
  464.    ^K              up arrow
  465.    ^D              up caret
  466.    ^_              down caret
  467.    ^T              forall
  468.    ^U              there exists
  469.    ^B              alpha
  470.    ^C              beta
  471.    ^I              gamma
  472.    ^J              delta
  473.    ^O              partial delta  
  474.    ^N              infinity
  475.    ^M              circle +
  476.    ^V              circle x
  477.  
  478. Other special characters to look out for are the font-change characters,
  479. which are represented as a ^F followed by a digit or asterisk. A digit
  480. means to push font #N onto the stack; an asterisk means to pop the most
  481. recent font from the stack. You can clean up the code by replacing "\^F."
  482. with "". In format statements, ^P and ^Q are used to delimit text to
  483. be printed in a particular character style.
  484.      
  485. ----------------------------------------------------------------
  486. Subject: [2-13] History: Where did Lisp come from?
  487.  
  488. John McCarthy developed the basics behind Lisp during the 1956 Dartmouth
  489. Summer Research Project on Artificial Intelligence.  He intended it as an
  490. algebraic LISt Processing (hence the name) language for artificial
  491. intelligence work. Early implementations included the IBM 704, the IBM
  492. 7090, the DEC PDP-1, the DEC PDP-6 and the DEC PDP-10. The PDP-6 and
  493. PDP-10 had 18-bit addresses and 36-bit words, allowing a CONS cell to
  494. be stored in one word, with single instructions to extract the CAR and
  495. CDR parts. The early PDP machines had a small address space, which
  496. limited the size of Lisp programs. 
  497.  
  498. Milestones in the development of Lisp:
  499.  
  500.    1956            Dartmouth Summer Research Project on AI.
  501.  
  502.    1960-65         Lisp1.5 is the primary dialect of Lisp.
  503.  
  504.    1964-           Development of BBNLisp at BBN.
  505.  
  506.    late 60s        Lisp1.5 diverges into two main dialects:
  507.                    Interlisp (originally BBNLisp) and MacLisp.
  508.  
  509.    early 70s       Development of special-purpose computers known as Lisp
  510.                    Machines, designed specificly to run Lisp programs. 
  511.                    Xerox D-series Lisp Machines run Interlisp-D. 
  512.                    Early MIT Lisp Machines run Lisp Machine Lisp 
  513.                    (an extension of MacLisp).
  514.  
  515.    1969            Anthony Hearn and Martin Griss define Standard Lisp to
  516.                    port REDUCE, a symbolic algebra system, to a variety
  517.                    of architectures.  
  518.  
  519.    late 70s        Macsyma group at MIT developed NIL (New Implementation
  520.                    of Lisp), a Lisp for the VAX.
  521.  
  522.                    Stanford and Lawrence Livermore National Laboratory
  523.                    develop S-1 Lisp for the Mark IIA supercomputer.
  524.  
  525.                    Franz Lisp (dialect of MacLisp) runs on stock-hardware
  526.                    Unix machines.
  527.  
  528.                    Gerald J. Sussman and Guy L. Steele developed Scheme,
  529.                    a simple dialect of Lisp with lexical scoping and
  530.                    lexical closures, continuations as first-class objects,
  531.                    and a simplified syntax (i.e., only one binding per symbol).
  532.  
  533.                    Advent of object-oriented programming concepts in Lisp.
  534.                    Flavors was developed at MIT for the Lisp machine,
  535.                    and LOOPS (Lisp Object Oriented Programming System) was
  536.                    developed at Xerox. 
  537.  
  538.    early 80s       Development of SPICE-Lisp at CMU, a dialect of MacLisp
  539.                    designed to run on the Scientific Personal Integrated
  540.                    Computing Environment (SPICE) workstation.
  541.  
  542.    1980            First biannual ACM Lisp and Functional Programming Conf.
  543.  
  544.    1981            PSL (Portable Standard Lisp) runs on a variety of platforms.
  545.  
  546.    1981+           Lisp Machines from Xerox, LMI (Lisp Machines Inc) 
  547.                    and Symbolics available commercially.
  548.  
  549.    April 1981      Grass roots definition of Common Lisp as a description
  550.                    of the common aspects of the family of languages (Lisp
  551.                    Machine Lisp, MacLisp, NIL, S-1 Lisp, Spice Lisp, Scheme). 
  552.                    
  553.  
  554.    1984            Publication of CLtL1. Common Lisp becomes a de facto 
  555.                    standard.
  556.  
  557.    1986            X3J13 forms to produce a draft for an ANSI Common Lisp
  558.                    standard. 
  559.  
  560.    1987            Lisp Pointers commences publication.
  561.  
  562.    1990            Steele publishes CLtL2 which offers a snapshot of
  563.                    work in progress by X3J13.  (Unlike CLtL1, CLtL2
  564.                    was NOT an output of the standards process and was
  565.                    not intended to become a de facto standard.  Read
  566.                    the Second Edition Preface for further explanation
  567.                    of this important issue.) Includes CLOS,
  568.                    conditions, pretty printing and iteration facilities. 
  569.  
  570.    1992            X3J13 creates a draft proposed American National
  571.                    Standard for Common Lisp. This document is the
  572.                    first official successor to CLtL1. 
  573.  
  574. [Note: This summary is based primarily upon the History section of the
  575. draft ANSI specification. More detail and references can be obtained from
  576. that document. See [4-12] for information on obtaining a copy.]
  577. ----------------------------------------------------------------
  578. Subject: [2-14]  How do I find the argument list of a function?
  579.                  How do I get the function name from a function object?
  580.  
  581. There is no standard way to find the argument list of a function,
  582. since implementations are not required to save this information.
  583. However, many implementations do remember argument information, and
  584. usually have a function that returns the lambda list. Here are the
  585. commands from some Lisp implementations:
  586.  
  587.    Lucid:                               arglist
  588.    Allegro:                             excl::arglist
  589.    Symbolics:                           arglist
  590.    LispWorks:                           lw:function-lambda-list
  591.  
  592. CMU Common Lisp, new compiler:
  593.    #+(and :CMU :new-compiler)
  594.    (defun arglist (name)
  595.      (let* ((function (symbol-function name))
  596.             (stype (system:%primitive get-vector-subtype function)))
  597.        (when (eql stype system:%function-entry-subtype)
  598.          (cadr (system:%primitive header-ref function
  599.                                   system:%function-entry-type-slot)))))
  600.  
  601. If you're interested in the number of required arguments you could use
  602.  
  603.    (defun required-arguments (name)
  604.      (or (position-if #'(lambda (x) (member x lambda-list-keywords))
  605.                       (arglist name))
  606.          (length (arglist name))))
  607.  
  608. To extract the function name from the function object, as in
  609.         (function-name #'car) ==> 'car
  610. use the following vendor-dependent functions:
  611.  
  612.    Symbolics: (si::compiled-function-name <fn>)
  613.     (unless (si:lexical-closure-p <fn>) ...)
  614.    Lucid:     (sys::procedure-ref <fn> SYS:PROCEDURE-SYMBOL)
  615.     (when (sys:procedurep <fn>) ..)
  616.    Allegro:   (xref::object-to-function-name <fn>)
  617.    CMU CL:    (kernel:%function-header-name <fn>)
  618.    AKCL:      (system::compiled-function-name <fn>)
  619.    MCL:       (ccl::function-name <fn>)
  620.    Harlequin: (system::function-name <fn>)
  621.  
  622. If a vendor-dependent function does not exist, the following
  623. (inefficient) code maps over all symbols looking for one whose
  624. function-cell matches the function object.
  625.  
  626. (defun function-name (fobject)
  627.    (do-all-symbols (fsymbol)
  628.       (when (and (fboundp fsymbol)
  629.                  (eq (symbol-function fsymbol) fobject))
  630.         (return fsymbol))))
  631.  
  632. If a vendor supports FUNCTION-LAMBDA-EXPRESSION, the third value is
  633. the name of the function, if available.
  634.  
  635. ----------------------------------------------------------------
  636. Subject: [2-15] How can I have two Lisp processes communicate via unix sockets?
  637.  
  638. CLX uses Unix sockets to communicate with the X window server. Look at
  639. the following files from the CLX distribution for a good example of
  640. using Unix sockets from Lisp:
  641.         defsystem.lisp          Lucid, AKCL, IBCL, CMU.
  642.         socket.c, sockcl.lisp   AKCL, IBCL
  643.         excldep.lisp            Franz Allegro CL
  644. You will need the "socket.o" files which come with Lucid and Allegro.
  645. To obtain CLX, see the entry for CLX in the answer to question [7-1].
  646.  
  647. See the file lisp-sockets.text in the Lisp Utilities repository
  648. described in the answer to question [6-1].
  649.  
  650. ----------------------------------------------------------------
  651. Subject: [2-16]  How can I create a stream that acts like UNIX's /dev/null
  652.                  (i.e., gobbles any output and immediately signals EOF on
  653.                  input operations)?
  654.  
  655. (defparameter *dev-null*
  656.   #-lispm
  657.   (make-two-way-stream (make-concatenated-stream) (make-broadcast-stream))
  658.   ;; Since Lisp Machines have a built-in /dev/null which handles
  659.   ;; additional, non-standard operations, we'll use that instead.
  660.   #+lispm #'system:null-stream)
  661.  
  662. ----------------------------------------------------------------
  663. ;;; *EOF*
  664.